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(57) Abstract: According to the invention, a domain 
lo be published to an enterprise ECDN is associated 
(either by static configuration or dynamically) with a 
set of one or more enterprise zones configurable in a 
hierarchy. When a DNS query arrives for a hostname 
known to be associated with given content within 
the control of the ECDN, a DNS server preferably 
responds in one of three (3) ways; handing back 
an IP address, e.g., for an ECDN intelligent node 
that knows how to obtain the requested content 
from a surrogate or origin server, executing a zone 
referral to a next (lower) level name server in a 
zone hierarchy, or CNAMing to another hostname, 
thereby essentially restarting the lookup procedure. 
In the latter case, this new CNAME causes the 
resolution process to start back at the root and 
resolve a new path, probably along a different path 
in the hierarchy. At any particular level in the 2one 
hierarchy, preferably there is an associated zone 
server. That server preferably executes logic that 
applied the requested hostname against a map, 
which, using known techniques, may be generated 
from given (static, dynamic, internally-generated or 
third party-sources) performance metrics. Thus, a 
given name query to ECDN-managed content may 
be serviced in coordination with various sources 
of distributed network intelligence. As a result, the 
invention provides for a distributed, dynamic globally 
load balanced name service. 
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USING VIRTUAL DOMAIN NAME SERVICE (DNS) ZONES 
FOR ENTERPRISE CONTENT DELIVERY 

BACKGROUND OF THE INVENTION 

This application is based on and claims priority from Provisional 
5 Application Serial No. 60/262, 1 7 1 filed January 1 6, 200 1 . 
Technical Field 

The present invention relates generally to content delivery and 
management within a private enterprise network. 
Description of the Related Art 
10 It is well-known to deliver digital content (e.g., HTTP content, streaming 

media and applications) using an Internet content delivery network (ICDN). A 
content delivery network or "CDN" is a network of geographically distributed 
content delivery nodes that are arranged for efficient delivery of content on behalf 
of third party content providers. A request from a requesting end user for given 
15 content is directed to a "best" replica, where rr best" usually means that the item is 
served to the client quickly compared to the time it would take to fetch it from the 
content provider origin server. 

Typically, a CDN is implemented as a combination of a content delivery 
infrastructure, a request-routing mechanism, and a distribution infrastructure. The 
20 content delivery infrastructure usually comprises a set of "surrogate" origin servers 
that are located at strategic locations (e.g., Internet network access points, Internet 
Points of Presence, and the like) for delivering copies of content to requesting end 
users. The request-routing mechanism allocates servers in the content delivery 
infrastructure to requesting clients in a way that, for web content delivery, 
25 minimizes a given client's response time and, for streaming media delivery, 
provides for the highest quality. The distribution infrastructure consists of on- 
demand or push-based mechanisms that move content from the origin server to the 
surrogates. An effective CDN serves frequently-accessed content from a surrogate 
that is optimal for a given requesting client. In a typical CDN, a single service 
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provider operates the request-routers, the surrogates, and the content distributors. 
In addition, that service provider establishes business relationships with content 
publishers and acts on behalf of their origin server sites to provide a distributed 
delivery system. A well-known commercial CDN service that provides web 
5 content and media streaming is provided by Akamai Technologies, Inc. of 
Cambridge, Massachusetts. 

Enterprises have begun to explore the desirability of implementing content 
delivery infrastructures to address several problems. Currently, enterprise users 
typically experience slow and expensive access to Internet content. Slow access to 
1 0 business critical data available on the Internet hurts productivity, and the cost of 
providing good access, e.g., by building bigger networks and by deploying and 
managing caching infrastructure, is large. In addition, many IT organizations 
cannot deliver the required quality of service for Internet content delivery due to 
lack of talent and expertise. Yet another reason corporations are exploring CDNs 
1 5 is because of the slow, expensive and often cumbersome access to and within the 
entity's intranet. As corporate intranets quickly become a critical component of 
business process in many large companies, fast and efficient access to the data and 
applications on the intranet is a high priority for many IT departments. 
Nevertheless, current intranet delivery solutions are inadequate, and solving the 
20 problems, e.g., by building bigger internal networks, deploying and managing 

caches, and distributing application front ends, is extremly expensive. To address 
these deficiencies, several large software vendors are attempting to build 
ecosystems to provide web-based front ends to many enterprise applications, 
however, distributing these application from front ends efficiently, in of itself, will 
25 be a critical IT problem that current technologies do not addresss. Finally, 

enterprises are considering CDN technology due to slow, expensive access to 
business partner applications and information provided by current techniques and 
solutions. Business-to-business applications (such as ordering, inventory, and 
pricing management) between business partners is done today by linking partners 
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with a physical network. These applications are moving to the Internet/intranet, 
and the need to link business partners together in an efficient way with web-based 
front ends is another critical IT problem that is not addressed by today's solutions. 
BRIEF SUMMARY OF THE INVENTION 
5 It is a general object of the invention to define and implement one or more 

virtual zones within an enterprise namespace to facilitate enterprise content 
delivery behind a corporate firewall. 

It is another general object of the present invention to provide an enterprise 
content delivery network that coexists with existing or "legacy" Domain Name 
1 0 Service (DNS) infrastructure to facilitate mapping of requests for enterprise 
resources to surrogate servers, e.g., common caching appliances, application 
servers, distributed storage and database management systems, and streaming 
media servers. 

It is yet another general object of the invention to define and implement 
15 one or more so-called "virtual" zones within an enterprise namespace to facilitate 
content delivery behind a corporate firewall over an enterprise content delivery 
network (ECDN). 

Another object of the present invention to enable an ECDN DNS to coexist 
with an existing enterprise DNS and to enable content delivery with only minimal 
20 configuration changes to the existing infrastructure using virtual zones. A given 
host or sub-domain to be published to the ECDN is aliased into a virtual zone 
namespace preferably using a DNS Canonical Name (CNAME). 

A still further object of the invention is to implement an enterprise content 
delivery network wherein any arbitrary hierarchical namespace can be 
25 implemented and wherein each layer of the namespace inherits the namespace 
above. 

According to the invention, a domain to be published to an enterprise 
ECDN is associated (either by static configuration or dynamically) with a set of 
one or more enterprise zones configurable in a hierarchy. AVhen a DNS query 
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arrives for a hostname known to be associated with given content within the 
control of the ECDN, a DNS server preferably responds in one of three (3) ways: 
(a) handing back an IP address, e.g., for an ECDN intelligent node that knows how 
to obtain the requested content from a surrogate or origin server; (b) executing a 
5 zone referral to a next (lower) level name server in a zone hierarchy, or (c) 
CNAMing to another hostname, thereby essentially restarting the lookup 
procedure. In the latter case, this new CNAME causes the resolution process to 
start back at the root and resolve a new path, probably along a different path in the 
hierarchy. At any particular level in the zone hierarchy, preferably there is an 
1 0 " associated zone server. That server preferably executes logic that applies the 
requested hostname against a map, which, using known techniques, maybe 
generated from given (static, dynamic, internally-generated or third party-sourced) 
performance metrics. Thus, a given name query to ECDN-managed content may 
be serviced in coordination with various sources of distributed network 
1 5 intelligence. As a result, the invention provides for a distributed, dynamic 
globally load balanced name service. 

According to a more specific aspect of the invention, a domain to be 
published to the ECDN is associated (either by static configuration or 
dynamically) with a set of one or more enterprise zones configurable in a 
20 hierarchy. When a request for content is received from a given client in the 
enterprise (or otherwise accessible through the firewall), a name query to the 
enterprise's legacy DNS is directed to the configured ECDN zone primary server. 
This primary ECDN zone server associates, and relays via CNAME, a name query 
with an ECDN intelligent node (or resolves directly to a given content origin 
25 server). This association may be based on given conditions within the network, 
server load conditions, or some combination of various known metrics. With 
ECDN virtual zones, maps that associate a given request to a server may be local 
or global, static or dynamic. While the maps typically are generated within the 
ECDN infrastructure, they could also be affected be external agents providing 
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hints or modifications. If multiple zones are used in a hierarchy, a first level 
ECDN zone server directs the name query to a second level ECDN zone server, 
and so on, until the appropriate response is generated. At any one level the 
particular zone server need not be able to resolve the entire name; rather, the 
5 particular zone server need only be able to resolve the portion required for 
directing the next level of resolution. For example: the zone server for the 
namespace containing b in the hostname a.b.c.d.e may have no idea where the 
final resolution will end up, but it should know which set of servers may be 
authoritative for the namespace containing c. Because DNS readily allows one to 
1 0 "carve out" zones in the namespace of a partcular domain (e.g., 

ecdn.company.com can be managed by a different authoritative DNS server than 
the rest ofcompany.com), the creation of the first level ECDN zone on the 
existing DNS infrastructure allows the two systems to coexist and undergo 
modification in parallel without interference with one another. This enables the 
1 5 present invention to be readily integrated into an existing or legacy DNS solution 
with minimal reconfiguration. 

Thus, according to the invention, an existing DNS infrastructure is 
augmented with one or more ECDN zone servers, and requests for content to be 
delivered over the ECDN are resolved through the one or more zone servers. In 
20 one embodiment, this function is achieved by identifying a given enterprise 

domain to be published to the ECDN, and having a network administrator (or a 
person acting on the administrator's behalf) modify an existing DNS name record 
for that enterprise domain. In this embodiment, the administrator CNAMEs the 
enterprise domain to a domain identified by a so-called "virtual zone" that is 
25 managed on an ECDN zone server (and, thus, forms part of the ECDN). In 
particular, this process enables the enterprise domain to be managed (by the 
enterprise or a third party acting on the enterprise's behalf) as part of the ECDN, 
typically by the ECDN zone server on one of the intelligent nodes (or some other 
machine, such as a client name server). A similar process is repeated for every 
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new domain or subdomain being distributed by the ECDN. Any client 
downloading a URL referring to the enterprise domain then gets directed to the 
ECDN zone server, which directs the client to an ECDN intelligent node. The 
client passes a host header to the ECDN node to identify the actual host. 

5 The foregoing has outlined some of the more pertinent features of the 

present invention. These features should be construed to be merely illustrative. 
Many other beneficial results can be attained by applying the disclosed invention 
in a different manner or by modifying the invention as will be described. 
BRIEF DESCRIPTION OF THE DRAWINGS 

1 o Figure 1 is a block diagram of an enterprise in which the inventive 

enterprise content delivery network (ECDN) may be implemented; 

Figure 2 is another enterprise environment in which the present invention 

may be implemented; 

Figure 3 illustrates a known technique for handling a request for content in 

1 5 an enterprise using a legacy DNS infrastmcture; 

Figure 4 illustrates a technique for enterprise content delivery using virtual 
DNS zones according to the present invention; 

Figure 5 illustrates a representative DNS namespace in which an enterprise 
virtual zone is created according to the present invention; 

Figure 6 illustrates a zone hierarchy in which first and second level ECDN 
zone servers are used to resolve a name query to an enterprise domain that has 

published to the ECDN; and 

Figure 7 illustrates a technique for dynamic zone creation through an 
agent-hinted CNAME according to the present invention; and 
25 Figure 8 illustrates a technique for using virtual zones to enable an 

enterprise partner to access an enterprise ECDN to retrieve intranet content. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention is implemented within an "enterprise" or "enterprise 
environment." Referring to Figure 1 , a representative enterprise environment in 
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which the present invention is implemented comprises at least one primary central 
office 100 (e.g., with central IT support), which is connected to one or more 
regional datacenters 102, with each datacenter connected to one or more remote 
branch offices 104 via private line, or via the public Internet (most likely with a 
virtual private network or "VPN"). The branch offices 104 may be fully (or 
partially) meshed amongst themselves. Figure 2 illustrates another enterprise 
computing environment that includes a central office 200 and a pair of remote 
offices 202. As shown in Figure 2, remote office 202a is connected to the central 
office 200 over a private line, which refers to a line not generally routable over the 
public Internet (e.g., frame relay, satellite link, microwave link, or the like), and 
remote office 202b is connected to the central office 200 over a virtual private 
network (VPN) typically over the public Internet, or in other known ways. A 
given remote office may be an office of an enterprise business partner if an 
appropriate business relationship between the enterprise and the partner exists. 

Enterprise networks are generally based on one one of two network types - 
point-to-point private/leased line, or VPN over public lines (often fully meshed 
between offices). From a topological view, actual enterprise networks may not 
operate in a hierarchical sense for connectivity. From a logical management view, 
however, the servers remain in a relatively weak hierarchy (as illustrated in either 
Figure 1 or 2) with more valuable and management intensive systems usually 
exisiting at more centralized data centers, and very few of these types of systems 
being deployed in remote branched offices. This architecture is usually a function 
of where information and management reside, which drives the cost of 
management for the overall IT network and IT services. Thus, for example, in the 
more complex enterprise such as shown in Figure 1 , regional datacenters tend to 
have more critical information than branch offices, and the central office tends to 
have the most critical information. It is assumed for purposes of illustration that 
the enterprise hosts given internal content that it desires to have stored, cached and 
delivered to end users in the enterprise. Such internal enterprise content, or 
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ECDN content, generally is non publicly-available content (in whatever format) 
that an enterprise desires to make available to permitted users within the enterprise 
or within a third party partner of the enterprise. An end user typically operates a 
computer having an Internet browser. The authoritative content and application 
5 servers 1 06 (in Figure 1) and 206 (in Figure 2) being published into the CDN 
(each identified here as an "ECDN server") can exist in any location, although 
from a practical perspective they may often be somewhat centrally-located. Such 
servers are sometimes referred to an origin servers. The enterprise is also assumed 
to be IP based and to have a Domain Name Service (DNS) 1 08 (in Figure 1) and 
10 208 (in Figure 2). From a security standpoint, the enterprise network manager 
roughly divides the world of the network into trusted and un-trusted, which 
usually corresponds to internal and external entities. Firewalls 1 10 (in Figure 1) 
and 2 10 (in Figure 2) are typically configured to allow most outbound traffic, with 
severe restrictions on inbound traffic. This allows for access to requested services 
1 5 without providing third parties a foothold for intrusion. More sophisticated 

systems usually create an security entity called a DMZ, which can be thought of as 
a set of two firewalls, with certain assets like email, DNS, web servers, etc. sitting 
between them. Each firewall has a different set of filtering rules, with the 
innermost generally allowing valid traffic from a host within the DMZ to enter the 
20 enterprise. Generally, no externally initiated traffic is allowed to pass both sets of 
filters. 

For purposes of illustration, an enterprise content delivery network 
(ECDN) is provisioned into the enterprise network topology of Figure 2. The 
ECDN may be implemented in a standalone manner, or it may be part of a larger 
25 Internet CDN, in which case the Internet CDN service provider may manage the 
ECDN on behalf of the enterprise. Various techniques for extending an ICDN 
into an enterprise are described in copending application Serial No. xx/xxx,xxx, 
filed January 7, 2002, titled EXTENDING AN INTERNET CONTENT 
DELIVERY NETWORK INTO AN ENTERPRISE, and in copending 



WO 02/0696(18 PCT/US02/01079 



application Serial No. yy/yyy,yyy, filed January 7, 2002, titled EXTENDING AN 
INTERNET CONTENT DELIVERY NETWORK INTO AN ENTERPRISE 
ENVIRONMENT BY LOCATING ICDN CONTENT SERVERS 
TOPOLOGICALLY NEAR AN ENTERPRISE FIREWALL, which 
5 applications are commonly-owned and which are incorporated herein by reference. 
Referring back to Figure 2, ECDN functionality is provided by locating one or 
more intelligent nodes (each referred to as an IN) that execute appropriate 
management, provisioning, monitoring and routing applications to facilitate the 
distribution, delivery and management of the private enterprise content delivery 
1 0 network. Thus, for example, an IN 212a may be located in the central office 200 
and each of the remote offices may include an IN box 212b as indicated. An IN 
box 212 is typically a computer, namely, a server, having at least one Pentium- 
class processor, an operating system (e.g., Linux, Windows NT, Windows 2000, 
or the like), and some amount of disk storage and system memory. Using the IN 
1 5 boxes, the enterprise (or the CDNSP on its behalf) has the ability to map and load 
balance users inside the enterprise (perhaps as part of the global ICDN), to fetch 
content from inside the firewall, to collect log information, to deploy software, to 
distribute live streams, and to provide other ICDN functionality. 

Thus, an illustrative enterprise CDN ("ECDN'*) is comprised of a variety 
20 of origin and surrogate servers and a distributed set of intelligence nodes (IN). An 
origin server can be any server that is intended to respond to a user request for 
information and includes, for example, common caching appliances, application 
servers, distributed storage and database management systems, and streaming 
media servers. The intelligence nodes tie the entire set of distributed nodes and 
25 services into a single, virtual service cloud. The ECDN intelligence nodes may 
have different configurations. Thus, for example, a first type (e.g., IN 212a in 
central office 200) may be sized (in terms of processing power and memory) for 
the largest datacenters, and such machines would be aggregation points for 
monitoring, logging, management and request routing. A second type of 
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intelligence node (e.g., IN 212b) may be sized for branch office deployment, and 
such servers would be sized to optimize local behavior. The nodes may be placed 
in a hierarchy with an IN of the first type acting as a parent. An intelligence node 
of the second type would typically include a caching engine. 
5 Architecturally, an ECDN such as illustrated above is similar to an Internet 

content delivery network (ICDN) and comprises: HTTP, streaming and DNS 
server nodes deployed across a customer network. Generalizing, the ECDN 
provides the enterprise with the following: a namespace and an associated request 
routing mechanism (to control how to navigate the CDN), storage, caching and 
10 streaming (to control how and where are objects stored and distributed), optionally 
an application environment (to facilitate application extensibility), management 
and provisioning (to control how the CDN is deployed and managed), and 
reporting/auditing (to provide visibility into the behavior). An ECDN such as 
described above provides an application, streaming and content delivery platform 
15 so that enterprise content may be delivered and managed in a decentralized fashion 
while providing a tightly-integrated solution with a customer's storage, network, 
application and management solutions. 

Enterprises today either outsource their Domain Name Service (DNS) or, 
as described above, run a DNS infrastructure (e.g., one or more DNS servers). A 
20 DNS namespace has certain characteristics, as are well-known. Each unit of data 
in a DNS distributed database is indexed by a hostname. These names are simply 
leaves in a tree representation, which is often called a domain namespace. Each 
node in the tree is labeled with a simple name. The fully qualified hostname of 
any node in the tree is the sequence of lables on the path from that node to the 
25 root. A zone is a subtree of the domain name space. Names at the leaves of the 
tree generally represent individual hosts, whose names resolve to one or more IP 
addresses. It has become common in instances of virtual hosting within ISPs to 
have multiple customers share a single machine, therefore having multiple 
hostnames reolve to a single machine or server farm. CDN technology to date has 



RNSDOCtD: <WO _Q20S960aA2_L> 




WO 02V069608 " PCTAJS02/01079 

11 

additionally made it common for a single hostname to potentially resolve to any 
one of thousands of machines, though at any given time the set of possible 
hostnames is configured and fixed. The term zone usually relates to a set of hosts 
within a single authoritative server's namespace, whereas a single zone could 
5 include multiple sub-domains. Thus, e.g., iffoo.com and eng.foo.com are both 
handled by the same nameserver, they are both in the same zone; but, if foo.com's 
nameserver refers a lookup to a different authority for resolution, they would be 
considered separate zones. 

An organization administrating a domain can divide it into subdomains. 
10 Each of those subdomains can be delegated to other organizations, in which case 
the organization receiving the delegation becomes responsible for maintaining all 
the data in that subdomain. The machines or programs executing on those 
machines that store information about the domain namespace are often called 
name servers. Name servers generally have complete information about some part 

1 5 of the doman namespace, namely, a zone. In such case, the name server is then 
said to have authority for that zone. A name server can also maintain cached 
information - or non-authoritative information, which is obtained by 
communicating with an authoritative name server. A zone contains the domain 
names and data that a domain contains, except for domain names and data that are 

20 delegated elsewhere. If a subdomain of the domain has not been delegated, the 
zone also contains the domain names and data in the subdomain. 

For purposes of the present invention, it is assumed that the enterprise 
operates (or has operated) DNS servers, that those servers manage data held in 
zones, and that each zone is a complete database for a particular "pruned" subtree 

25 of the domain space. As noted above, the zone data is authoritative, in that it 
contains an accurate (typically, the most accurate) representation available for a 
particular set of hostnames. At least one host in the enterprise stores enterprise 
content that the enterprise desires to make available to permitted end users 
(enterprise or partner employees). The enterprises use the existing DNS 
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infrastructure to resolve client requests for content at that host. Figure 3 illustrates 
the known prior art. In this example, it is assumed that the user desires to retrieve 
the enterprise internal homepage, which is a page located, in this example, at 
http://hr.company.commomepage.html. To this end, the user, or client 300, 
5 interacts with DNS via a resolver 302, typically residing on the same machine. As 
is well-known, a resolver is a client process that accesses a name server. 
Programs running on a host that need information from a domain name space use 
the resolver. In DNS BIND, for example, the resolver is a set of library routines 
that query a name server, interpret responses, and return the information to the 
10 program/process that requested it. Thus, with reference to Figure 3. the resolver 
302 interacts with the enterprise name server 304 to resolve client queries, which 
are then returned to the client. In the example shown in Figure 3, the client 
resolver 302 makes a DNS request (in this example "who is hr.company.com?") to 
the corporate DNS name server 304, which returns a reply with an actual IP 
1 5 address y.y.y.y of the host on which the document is stored. The client resolver 
302 then uses a DNS A record to build a connection to the actual web server 306, 
and issues an appropriate HTTP request to the web server 306 (e.g., via a GET 
http-Z/hr comnanv. ^/hnn.eDaee.htmn . The web server 306 responds with the 
content reply to complete the request. 
20 According to the invention, the existing DNS infrastructure is augmented 

with one or more ECDN zone servers, and requests for content to be delivered 
over the ECDN are resolved through the one or more zone servers. In the 
simpliest embodiment, this function is achieved by identifying a given enterprise 
domain to be published to the ECDN, and having a network administrator (or a 
25 person acting on the administrator's behalf) modify an existing DNS name record 
for that enterprise domain. In this embodiment, the administrator CNAMEs the 
enterprise domain to a domain identified by a so-called "virtual" zone that is 
managed on an ECDN zone server (and, thus, forms part of the ECDN). In 
particular, this process enables the enterprise domain to be managed (by the 
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enterprise or a third party acting on the enterprise's behalf) as part of the ECDN, 
typically by the ECDN zone server on one of the intelligent nodes (or some other 
machine, such as a client name server). A similar process is repeated for every 
new domain or subdomain being distributed by the ECDN. Any client 
downloading a URL referring to the enterprise domain then gets directed to the 
ECDN zone server, which directs the client to an ECDN IN. The client passes a 
host header to the ECDN IN to identify the actual host. 

Figure 4 illustrates an embodiment of the present invention. DNS requests 
typically occur over UDP, while HTTP requests typically occur over TCP. The 
enterprise is identified as "akamai" for illustrative purposes only. In this example, 
the client resolver 402 makes a DNS request for "hr.akamai.com" (step (1)) to the 
configured name server 404. This name server may be part of the legacy DNS 
infrastructure, as described above. This same name server 404 (running a suitable 
DNS BIND version) looks up hr.akamai.com and sees that the hostname resides 
within the zone configured to be within the ECDN (potentially after first resolving 
a CNAME from hr.akamai.com to itself for hr.ecdn.akamai.com). At step (3), the 
query is then referred to an ECDN name server 406, with the ECDN name server 
being configured to be authoritative for the ecdn.akamai.com zone. Some of the 
steps are compressed in the figure for clarity. At step (4), the ECDN zone server 
406 could do one of three things: reply with an IP address x.x.x.x, pass the query 
to a different zone for hr.ecdn.akamai.com, or CNAME the request to a different 
hostname all together (restarting this process). In the drawing, the ECDN zone 
server has returned the IP address. Thus, at step (5), the client makes an HTTP 
request to the ECDN IN 408 at IP address x.x.x.x with a host header: identifying 
the host hr.akamai.com. At steps (6), (7) and (8), the ECDN content server 
handles the HTTP portion of the request in the standard fashion for a surrogate. 
The content is served from the origin server 406. 

The technique shown in Figure 4 provides significant advantages. 
According to the invention, when a DNS query arrives for a hostname known to 
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be associated with given content within the control of (i.e., managed by) the 
ECDN, the DNS server that receives the query preferably responds in one of three 
(3) ways: (a) handing back an IP address, e.g., for an ECDN intelligent node that 
knows how to obtain the requested content from a surrogate or origin server (as 
5 illustrated in Figure 4); (b) executing a zone referral to a next (lower) level in a 
zone hierarchy (as defined in standard DNS), or (c) CNAMing to another 
hostname, thereby essentially restarting the lookup procedure. This new CNAME 
cause the resolution process to start back at the root and resolve a new path, 
probably along a different path in the hierarchy. At any particular level in the zone 
1 0 hierarchy, there is preferably an associated zone server. Zone servers may operate 
on the same machines but typically have different IP addresses. Each zone server 
preferably executes logic that applies the requested hostname against a map which, 
using known techniques, may be generated from given (static, dynamic, internally- 
generated or third party-sourced) performance metrics. Thus, a given name query 
1 5 to ECDN-managed content may be serviced in coordination with various sources 
of distributed network intelligence. As a result, the invention provides for a 
distributed, dynamic globally load balanced name service for an enterprise CDN. 

From a logical view, hierarchical DNS zones for resolving a particular 
query within a content delivery network are represented according to the present 
20 invention as illustrated in Figure 5. In this example, it is assumed that an Internet 
CDN service provider operates over a namespace that is referred to as "akamai." 
This namespace includes a subdomain of *. ecdn.akamai.com, which, as noted 
above, is the virtual zone. In this example, the CDNSP manages the zone on the 
enterprise's behalf. In a normal name query, a request for foo.akamai.com returns 
25 some IP address, which is normally fixed. With web hosting, as is well-known, 
virtual hostnames are often used to allow a single address to handle multiple 
hostnames. For load balancing, a round robin technique is often used, allowing 
for one name to be spread across multiple addresses. For virtual zones, preferably 
there is a many-to-many mapping. In particular, one hostname is spread across a 
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mesh of servers, and one server may handle any number of hostnames. Thus, for 
example, in a simple case, one could create three (3) hostnames (x, y, and z) and 
have four (4) servers (having IP addresses: 1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4). Any 
hostname query could resolve to any server address, giving twelve (12) 
combinations of responses to any particular query. Thus, when the server for this 
virtual zone gets a request, it replies with any of the 12 possible addresses, 
although significant performance advantages could be gained if it were to use a 
more intelligent approach. In particular, it is also well-known that geographical 
and topological location information can be used to send clients to the closest 
address, and server load can be accounted for as well to try and optimize client 
response times. A combination of these (with other factors) can be used to 
determine the best server for handling a particular request. 

As described above, so-called Canonical Name (CNAME) records define 
an alias for an official hostname and are part of the DNS standard. In general, 
CNAMEing may be thought of as a means for DNS redirection of a client query. 
As illustrated above, DNS virtual zones and CNAMEs are used with standard 
surrogate servers to manage ECDN content in a given enterprise. 

The CNAME technique may be implemented any number of arbitrary 
times, while zone referral preferably occurs hierarchically. Generalizing, 
according to the invention, a given domain may be of the form 
"*.zone2.zonel .enterprise.com*' where "zonel " represents a first or "top" level 
ECDN zone, "zone2 "represents a second or "lower" level ECDN subzone of the 
top level zone, and so forth. As indicated in Figure 6, a first level ECDN zone 
server 600 would handle top level resolutions, and one or more second level 
ECDN zone servers 602 would handle the next level resolutions, and so forth. 
The wildcard in the above example indicates that further zone levels may be 
provided as well, with each level of the zone hierarchy then inheriting the 
namespace of the levels above it. Thus, the 'Virtual" nature of the invention is due 
to the fact that at no time is there necessarily a fixed set of possible hostnames - 
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they may be, and most likely are, produced on-the-fly. Thus, for example, if the 
enterprise uses an Oracle database for storing financial data, the network 
administrator may generate domains such as "financials.ecdn.company.com," 
while the ECDN itself may be creating objects like 
5 "component.oracle.financials.ecdn.company.com," or 

"a b coracle.nnancials.ecdn.company.com" etc. Continuing with this example, if 
a particular ECDN zone server is provided with a name it does not fully recognize, 
it resolves that portion that is can recognize. Thus, while a first-level ECDN DNS 
server might do a rough cut of performance and refer a request to another zone, the 
10 next zone may have a finer grainmetric used for next step resolution. 

According to the invention, and as illustrated in Figure 6, assume that 
given enterprise content has been published to the ECDN and, in particular, to be 
nonaged by a second level zone server «hr.ecdn.akamai.com." In this example, a 
request for resolution ofhr.akamai.com is first directed (through a CNAME) to the 
15 ecdn.akamai.com top level zone server 600, which then redirects the request 
(again through a CNAME) to one of the hr.ecdn.akamai.com second level zone 
- servers 602. The second level name servers may be load balanced, e.g., based on 
network information collected at the zone server pair about connectivity between 
the remote office and possible locations of the backend servers that host the 
20 desired content, as well state information about the load on those servers. The 
second level name server returns the IP address of an optimal backend server 
based on the available metrics (e.g., server load, network connectivity, etc.). The 
use of hierarchical zones in this manner enables the enterprise to build and 
maintain more relevant "local" information about how client requests should be 
25 mapped, thus obviating the building, maintenance and delivery of enterpnse-wide 

request routing maps. 

According to another feature of this invention, a software agent is executed 
in or in conjunction with a DNS server to create "zones" dynamically. In this 
approach, the agent, in effect, provides hints to the enterprise DNS name server as 
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to which enterprise domains would be beneficially cached, as well as the addresses 
of near-by (local) ECDN intelligent nodes. Figure 7 illustrates the agent-hinted 
CNAME technique. To create such as agent, the enterprise may keep a 
lightweight history databases within a DNS server, recording usage patterns of A 
(address) record lookup requests. Building heuristics around access patterns or 
looking for high or relatively increased lookups on a per domain basis might 
provide candidate hostnames. This would identify high usage HTTP sites. The 
hints might also come from firewalls, third party updates, in-line L4 switches, or 
from some other entity listening on port 80 (e.g., perhaps via an egress switch 
SPAN port). When a domain is identified as potentially interesting from a usage 
perspective, instead of returning the address of the actual domain, the address of a 
nearby ECDN IN may be substituted dynamically. After traffic dies down, the 
address could revert back to standard behavior. Thus, if the "hot" domain is 
"hr.akamai.com," the DNS name server dynamically CNAMEs the domain to the 
local ECDN zone server "ecdn.akamai.com" as needed. All traffic to the 
hr.akamai.com would then get sent to the close-by ECDN IN for handling. Agent 
interaction may be accomplished as a server plugin, through WCCP 2.0 
transparent interception of DNS traffic, promiscuous DNS port snooping (SPAN 
mode), or providing an augmented DNS name server. An interface may be 
provided to notify the agent that all *. ecdn.enterprise.com servers are part of the 
ECDN and should be sent towards the appropriate servers. 

The present invention provides numerous advantages over the prior art. 
According to the invention, a domain to be published to the ECDN is associated 
(either by static configuration or dynamically) with a set of one or more enterprise 
zones configurable in a hierarchy. When a request for content is received from a 
given client in the enterprise (or otherwise accessible through the firewall), a name 
query to the enterprise's legacy DNS is directed (preferably via CNAME) to a set 
of one or more ECDN zone servers. A given ECDN zone server associates a 
name query with an ECDN intelligent node (or to a given content server). This 
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association may be based on given conditions within the network, server load 
conditions, or some combination of various known metrics. With ECDN virtual 
zones, maps that associate a given request to a server may be local or global, static 
or dynamic. If multiple zones are used in a hierarchy, a first level ECDN zone 
5 server redirects the name query to a second level ECDN zone server, and so on, 
until the appropriate response is generated. ECDN zone servers may reside on the 
same machine or with existing DNS infrastructure or other machines in the 
enterprise. This enables the present invention to be readily integrated into an 
existing or legacy DNS solution with rninimal reconfiguration. 
I o As described and illustrated above, a given zone may have a sub-zone and, 

according to the invention, that sub-zone may be managed by the enterprise or 
even by a third party such as an Internet content delivery network (ICDN) service 
provider. As an example of the latter scenario, assume that the enterprise 
outsources its streaming video delivery to the ICDN service provider. To this end, 
15 a host lookup for, say, allhands.sn-eanungvideo.ecdn.company.com maybe 

configured either statically or dynamically to a zone managed by a CDN overlay 
network. This has the effect of transparently allowing delivery to be seemlessly 
tied internally and externally via the same mechanism. 

Figure 8 illustrates another example of how an enterprise may hand off 
20 management of a virtual zone to another entity, in this case an enterprise business 
partner. In this example, producer.com is the enterprise and consumer.com is the 
enterprise business partner having an end user. Producer.com desires to make 
given content available to the consumer.com end user, however, the producer.com 
namespace on which the content is published is not resolvable through public 
25 DNS and the document is not available publicly. Both producer.com and 

consumer.com are assumed to have implemented an ECDN system behind each of 
their respective firewalls,'and each entity has a private namespace that they 
respectively manage. The goal is to make producer.com ». namespace selectively 
available to an end user in consumer.com without, at the same time, exposing 
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producer.com's namespace to the public DNS. Each ECDN deploys a relay 
machine which, preferably, is a combination of a surrogate origin server and an 
ECDN zone server. Separate machines/processes may be used, or the processes 
may be integrated or included with other functionality. Preferably, each relay 
machine is located within the enterprise DMZ, as illustrated in the drawing. The 
relay machine inside consumer.com does not know how to resolve a virtual zone 
associated with producer.com, but that machine does know that the relay machine 
inside producer.com 's firewall does know how to make such a resolution. 
Likewise, the relay machine inside producer.com does not know how to resolve a 
virtual zone associated with consumer.com, but that machine does know that relay 
machine insideconsumer.com' s firewall make know how to make such a 
resolution. As is well-known, boxes within a DMZ can be selectively allowed to 
communicate with one another while filtering other potentially hostile 
communications. 

Referring back to Figure 8, assume that the document in question is 
referenced within consumer.com by a836.asp.producer.com/object.htrnl. In this 
example, the zone "asp.producer.com" has been designated within consvuner.com 
as being owned or managed by relay.consumer.com. Thus, relay.consumer.com 
will act as a surrogate for that document. When the consumer.com relay gets the 
host header a836.asp.producer.com, the relay machine uses that information to 
connect to the relay machine in producer.com. The relay machine in 
producer.com gets the HTTP request and it is configured to rewrite any host 
header (associated with a836.asp.producer.com in this example) to 
foo.producer.com. The relay machine at relay.producer.com then acts as a 
surrogate origin server for the web server at foo.producer.com, which hosts the 
document. The web server then returns the document via the surrogate origin 
server relay.producer.com, and that server rewrites the response header to point 
back to itself. The relay machine in producer.com then returns the data to the 
relay machine in consvuner.com, which performs similar surrogate processing and 
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returns the document to the requesting end user. This completes the processing. 
Thus, one of ordinary skill in the art will appreciate that, in this manner, 
producer.com has handed off management of the relay.producer.com virtual zone 
to consumer.com. This arrangement creates a VPN-like connection between the 
5 two namespaces to facilitate the document sharing. As illustrated, preferably the 
communications between the two relay machines are made over secure link using 

known techniques. 

Having thus described my invention, the following sets forth what I now 

claim. 

10 
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CLAIMS 



I. 



A content delivery method operative in an enterprise, comprising: 



10 



15 



establishing an enterprise content delivery network within the enterprise, 
wherein the enterprise content delivery network has associated therewith a set of 
one or more zones organized into a hierarchy; and 

in response to a name query for a hostname known to be associated with 
the given content being managed by the enterprise content delivery network, 
returning a response to the name query; 

wherein the response selectively (a) identifies a given node in the 
enteiprise content delivery network that can obtain the given content from a server 
within the enterprise, (b) causes a referral to a zone within the hierarchy, or (c) 
relays the name query to another path. 

2. The content delivery method as described in Claim 1 wherein, if 
the response identifies the given node, having the given node obtain the given 
content from the server. 

3. The content delivery method as described in Claim 1 wherein, if 
the response causes a zone referral, attempting to resolve the name query at a next 
level within the hierarchy. 

4. The content delivery method as described in Claim 1 wherein, if 
the response is relayed to another path, attempting to resolve the name query along 
that path. 

5. The content delivery method as described in Claim 1 further 
including the step 

publishing the given content into the enterprise content delivery network. 



BNSOOCID <WO_.02069S08A2J_> 



WO 02/069608 ■ PCT/US02/01079 



22 



6. The content delivery method as described in Claim 5 wherein the 
step of publishing comprises: 

identifying the hostname to be published to the enterprise content delivery 

network; 

5 aliasing the hostname to a given zone in the hierarchy. 

7. The content delivery method as described in Claim 6 wherein the 
aliasing step CNAMEs the hostname to a domain in which the virtual zone is 
prepended to at least a portion of the hostname. 

10 

8. The content delivery method as described in Claim 7 wherein the 
CNAME is generated statically. 

9. The content delivery method as described in Claim 7 wherein the 
1 5 CNAME is generated dynamically. 

10. The content delivery method as described in Claim 1 wherein the 
name query is resolved to the IP address of the given node as a function of given 
network or server metrics. 

20 

1 1 . The content delivery method as described in Claim 1 0 wherein the 
IP address of the given node is generated dynamically. 

12. The content delivery method as described in Claim 1 wherein the 
25 enterprise content delivery network is part of an Internet content delivery network 

(ICDN). 

13. The content delivery method as described in Claim 1 1 wherein the 
enterprise content delivery network is managed as part of the ICDN. 
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USING VIRTUAL DOMAIN NAME SERVICE (DNS) ZONES 
FOR ENTERPRISE CONTENT DELIVERY 

BACKGROUND OF THE INVENTION 

This application is based on and claims priority from Provisional 

5 Application Serial No. 60/262,17 1 filed January 16, 2001 . 
Technical Field 

The present invention relates generally to content delivery and 
management within a private enterprise network. 
Description of the Related Art 

10 It is well-known to deliver digital content (e.g., HTTP content, streaming 

media and applications) using an Internet content delivery network (ICDN). A 
content delivery network or "CDN" is a network of geographically distributed 
content delivery nodes that are arranged for efficient delivery of content on behalf 
of third party content providers. A request from a requesting end user for given 

1 5 content is directed to a "best" replica, where "best" usually means that the item is 
served to the client quickly compared to the time it would take to fetch it from the 
content provider origin server. 

Typically, a CDN is implemented as a combination of a content delivery 
infrastructure, a request-routing mechanism, and a distribution infrastructure. The 

20 content delivery infrastructure usually comprises a set of "surrogate" origin servers 
that are located at strategic locations (e.g., Internet network access points, Internet 
Points of Presence, and the like) for delivering copies of content to requesting end 
users. The request-routing mechanism allocates servers in the content delivery 
infrastructure to requesting clients in a way that, for web content delivery, 

25 minimizes a given client's response time and, for streaming media delivery, 
provides for the highest quality. The distribution infrastructure consists of on- 
demand or push-based mechanisms that move content from the origin server to the 
surrogates. An effective CDN serves frequently-accessed content from a surrogate 
that is optimal for a given requesting client. In a typical CDN, a single service 
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provider operates the request-routers, the surrogates, and the content distributors. 
In addition, that service provider establishes business relationships with content 
publishers and acts on behalf of their origin server sites to provide a distributed 
delivery system. A well-known commercial CDN service that provides web 
5 content and media streaming is provided by Akamai Technologies, Inc. of 
Cambridge, Massachusetts. 

Enterprises have begun to explore the desirability of implementing content 
delivery infrastructures to address several problems. Currently, enterprise users 
typically experience slow and expensive access to Internet content. Slow access to 

1 0 business critical data available on the Internet hurts productivity, and the cost of 
providing good access, e.g., by building bigger networks and by deploying and 
managing caching infrastructure, is large. In addition, many IT organizations 
cannot deliver the required quality of service for Internet content delivery due to 
lack of talent and expertise. Yet another reason corporations are exploring CDNs 

15 is because of the slow, expensive and often cumbersome access to and within the 
entity's intranet. As corporate intranets quickly become a critical component of 
business process in many large companies, fast and efficient access to the data and 
applications on the intranet is a high priority for many IT departments. 
Nevertheless, current intranet delivery solutions are inadequate, and solving the 

20 problems, e.g., by building bigger internal networks, deploying and managing 

caches, and distributing application front ends, is extremly expensive. To address 
these deficiencies, several large software vendors are attempting to build 
ecosystems to provide web-based front ends to many enterprise applications, 
however, distributing these application from front ends efficiently, in of itself, will 

25 be a critical IT problem that current technologies do not addresss. Finally, 

enterprises are considering CDN technology due to slow, expensive access to 
business partner applications and information provided by current techniques and 
solutions. Business-to-business applications (such as ordering, inventory, and 
pricing management) between business partners is done today by linking partners 
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10 



15 



20 



with a physical network. These applications are moving to the Internet/intranet, 
and the need to link business partners together in an efficient way with web-based 
front ends is another critical IT problem that is not addressed by today's solutions. 
BRIEF SUMMARY OF THE INVENTION 

It is a general object of the invention to define and implement one or more 
virtual zones within an enterprise namespace to facilitate enterprise content 
delivery behind a corporate firewall. 

It is another general object of the present invention to provide an enterprise 
content delivery network that coexists with existing or "legacy" Domain Name 
Service (DNS) infrastructure to facilitate mapping of requests for enterprise 
resources to surrogate servers, e.g., common caching appliances, application 
servers, distributed storage and database management systems, and streaming 
media servers. 

It is yet another general object of the invention to define and implement 
one or more so-called 'Virtual" zones within an enterprise namespace to facilitate 
content delivery behind a corporate firewall over an enterprise content delivery 
network (ECDN). 

Another object of the present invention to enable an ECDN DNS to coexist 
with an existing enterprise DNS and to enable content delivery with only minimal 
configuration changes to the existing infrastructure using virtual zones. A given 
host or sub-domain to be published to the ECDN is aliased into a virtual zone 
namespace preferably using a DNS Canonical Name (CNAME). 

A still further object of the invention is to implement an enterprise content 
delivery network wherein any arbitrary hierarchical namespace can be 
implemented and wherein each layer of the namespace inherits the namespace 
above. 

According to the invention, a domain to be published to an enterprise 
ECDN is associated (either by static configuration or dynamically) with a set of 
one or more enterprise zones configurable in a hierarchy. When a DNS query 
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arrives for a hostname known to be associated with given content within the 
control of the ECDN, a DNS server preferably responds in one of three (3) ways: 
(a) handing back an IP address, e.g., for an ECDN intelligent node that knows how 
to obtain the requested content from a surrogate or origin server; (b) executing a 
5 zone referral to a next (lower) level name server in a zone hierarchy, or (c) 
CNAMing to another hostname, thereby essentially restarting the lookup 
procedure. In the latter case, this new CNAME causes the resolution process to 
start back at the root and resolve a new path, probably along a different path in the 
hierarchy. At any particular level in the zone hierarchy, preferably there is an 

10 ' associated zone server. That server preferably executes logic that applies the 
requested hostname against a map, which, using known techniques, may be 
generated from given (static, dynamic, internally-generated or third party-sourced) 
performance metrics. Thus, a given name query to ECDN-managed content may 
be serviced in coordination with various sources of distributed network 

15 intelligence. As a result, the invention provides for a distributed, dynamic 
globally load balanced name service. 

According to a more specific aspect of the invention, a domain to be 
published to the ECDN is associated (either by static configuration or 
dynamically) with a set of one or more enterprise zones configurable in a 

20 hierarchy. When a request for content is received from a given client in the 
enterprise (or otherwise accessible through the firewall), a name query to the 
enterprise's legacy DNS is directed to the configured ECDN zone primary server. 
This primary ECDN zone server associates, and relays via CNAME, a name query 
with an ECDN intelligent node (or resolves directly to a given content origin 

25 server). This association may be based on given conditions within the network, 
server load conditions, or some combination of various known metrics. With 
ECDN virtual zones, maps that associate a given request to a server may be local 
or global, static or dynamic. While the maps typically are generated within the 
ECDN infrastructure, they could also be affected be external agents providing 
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hints or modifications. If multiple zones are used in a hierarchy, a first level 
ECDN zone server directs the name query to a second level ECDN zone server, 
and so on, until the appropriate response is generated. At any one level the 
particular zone server need not be able to resolve the entire name; rather, the 

5 particular zone server need only be able to resolve the portion required for 
directing the next level of resolution. For example: the zone server for the 
namespace containing b in the hostname a.b.c.d.e may have no idea where the 
final resolution will end up, but it should know which set of servers may be 
authoritative for the namespace containing c. Because DNS readily allows one to 

10 "carve out" zones in the namespace of a partcular domain (e.g., 

ecdnxompany.com can be managed by a different authoritative DNS server than 
the rest ofcompany.com), the creation of the first level ECDN zone on the 
existing DNS infrastructure allows the two systems to coexist and undergo 
modification in parallel without interference with one another. This enables the 

1 5 present invention to be readily integrated into an existing or legacy DNS solution 
with minimal reconfiguration. 

Thus, according to the invention, an existing DNS infrastructure is 
augmented with one or more ECDN zone servers, and requests for content to be 
delivered over the ECDN are resolved through the one or more zone servers. In 

20 one embodiment, this function is achieved by identifying a given enterprise 

domain to be published to the ECDN, and having a network administrator (or a 
person acting on the administrator's behalf) modify an existing DNS name record 
for that enterprise domain. In this embodiment, the administrator CNAMEs the 
enterprise domain to a domain identified by a so-called "virtual zone" that is 

25 managed on an ECDN zone server (and, thus, forms part of the ECDN). In 
particular, this process enables the enterprise domain to be managed (by the 
enterprise or a third party acting on the enterprise's behalf) as part of the ECDN, 
typically by the ECDN zone server on one of the intelligent nodes (or some other 
machine, such as a client name server). A similar process is repeated for every 
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new domain or subdomain being distributed by the ECDN. Any client 
downloading a URL referring to the enterprise domain then gets directed to the 
ECDN zone server, which directs the client to an ECDN intelligent node. The 
client passes a host header to the ECDN node to identify the actual host. 
5 The foregoing has outlined some of the more pertinent features of the 

present invention. These features should be construed to be merely illustrative. 
Many other beneficial results can be attained by applying the disclosed invention 
in a different manner or by modifying the invention as will be described. 
BRIEF DESCRIPTION OF THE DRAWINGS 
1 0 Figure 1 is a block diagram of an enterprise in which the inventive 

enterprise content delivery network (ECDN) may be implemented; 

Figure 2 is another enterprise environment in which the present invention 
may be implemented; 

Figure 3 illustrates a known technique for handling a request for content in 
15 an enterprise using a legacy DNS infrastructure; 

Figure 4 illustrates a technique for enterprise content delivery using virtual 
DNS zones according to the present invention; 

Figure 5 illustrates a representative DNS namespace in which an enterprise 
virtual zone is created according to the present invention; 
20 Figure 6 illustrates a zone hierarchy in which first and second level ECDN 

zone servers are used to resolve a name query to an enterprise domain that has 
published to the ECDN; and 

Figure 7 illustrates a technique for dynamic zone creation through an 
agent-hinted CNAME according to the present invention; and 
25 Figure 8 illustrates a technique for using virtual zones to enable an 

enterprise partner to access an enterprise ECDN to retrieve intranet content. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention is implemented within an "enterprise" or "enterprise 
environment." Referring to Figure 1, a representative enterprise environment in 



BNSOOCID <WO__O2069608A3JA> 



WO 02/069608 ■ ■ PCT/US02/01079 



7 



which the present invention is implemented comprises at least one primary central 
office 100 (e.g., with central IT support), which is connected to one or more 
regional datacenters 102, with each datacenter connected to one or more remote 
branch offices 104 via private line, or via the public Internet (most likely with a 
5 virtual private network or "VPN")- The branch offices 1 04 may be fully (or 
partially) meshed amongst themselves. Figure 2 illustrates another enterprise 
computing environment that includes a central office 200 and a pair of remote 
offices 202. As shown in Figure 2, remote office 202a is connected to the central 
office 200 over a private line, which refers to a line not generally routable over the 
1 0 public Internet (e.g., frame relay, satellite link, microwave link, or the like), and 
remote office 202b is connected to the central office 200 over a virtual private 
network (VPN) typically over the public Internet, or in other known ways. A 
given remote office may be an office of an enterprise business partner if an 
appropriate business relationship between the enterprise and the partner exists. 
1 5 Enterprise networks are generally based on one one of two network types - 

point-to-point private/leased line, or VPN over public lines (often fully meshed 
between offices). From a topological view, actual enterprise networks may not 
operate in a hierarchical sense for connectivity. From a logical management view, 
however, the servers remain in a relatively weak hierarchy (as illustrated in either 
20 Figure 1 or 2) with more valuable and management intensive systems usually 

exisiring at more centralized data centers, and very few of these types of systems 
being deployed in remote branched offices. This architecture is usually a function 
of where information and management reside, which drives the cost of 
management for the overall IT network and IT services. Thus, for example, in the 
25 more complex enterprise such as shown in Figure 1 , regional datacenters tend to 
have more critical information than branch offices, and the central office tends to 
have the most critical information. It is assumed for purposes of illustration that 
the enterprise hosts given internal content that it desires to have stored, cached and 
delivered to end users in the enterprise. Such internal enterprise content, or 
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ECDN content, generally is non publicly-available content (in whatever format) 
that an enterprise desires to make available to permitted users within the enterprise 
or within a third party partner of the enterprise. An end user typically operates a 
computer having an Internet browser. The authoritative content and application 

5 servers 1 06 (in Figure 1 ) and 206 (in Figure 2) being published into the CDN 
(each identified here as an "ECDN server") can exist in any location, although 
from a practical perspective they may often be somewhat centrally-located. Such 
servers are sometimes referred to an origin servers. The enterprise is also assumed 
to be IP based and to have a Domain Name Service (DNS) 108 (in Figure 1) and 

1 0 208 (in Figure 2). From a security standpoint, the enterprise network manager 
roughly divides the world of the network into trusted and un-trusted, which 
usually corresponds to internal and external entities. Firewalls 1 10 (in Figure 1) 
and 210 (in Figure 2) are typically configured to allow most outbound traffic, with 
severe restrictions on inbound traffic. This allows for access to requested services 

1 5 without providing third parties a foothold for intrusion. More sophisticated 

systems usually create an security entity called a DMZ, which can be thought of as 
a set of two firewalls, with certain assets like email, DNS, web servers, etc. sitting 
between them. Each firewall has a different set of filtering rules, with the 
innermost generally allowing valid traffic from a host within the DMZ to enter the 

20 enterprise. Generally, no externally initiated traffic is allowed to pass both sets of 
filters. 

For purposes of illustration, an enterprise content delivery network 
(ECDN) is provisioned into the enterprise network topology of Figure 2. The 
ECDN may be implemented in a standalone manner, or it may be part of a larger 
25 Internet CDN, in which case the Internet CDN service provider may manage the 
ECDN on behalf of the enterprise. Various techniques for extending an ICDN 
into an enterprise are described in copending application Serial No. xx/xxx,xxx, 
filed January 7, 2002, titled EXTENDING AN INTERNET CONTENT 
DELIVERY NETWORK INTO AN ENTERPRISE, and in copending 
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application Serial No. yy/yyy,yyy, filed January 7, 2002, titled EXTENDING AN 
INTERNET CONTENT DELIVERY NETWORK INTO AN ENTERPRISE 
ENVIRONMENT BY LOCATING ICDN CONTENT SERVERS 
TOPOLOGICALLY NEAR AN ENTERPRISE FIREWALL, which 
5 applications are commonly-owned and which are incorporated herein by reference. 
Referring back to Figure 2, ECDN functionality is provided by locating one or 
more intelligent nodes (each referred to as an IN) that execute appropriate 
management, provisioning, monitoring and routing applications to facilitate the 
distribution, delivery and management of the private enterprise content delivery 

10 network. Thus, for example, an IN 212a may be located in the central office 200 
and each of the remote offices may include an IN box 212b as indicated. An IN 
box 212 is typically a computer, namely, a server, having at least one Pentium- 
class processor, an operating system (e.g., Linux, Windows NT, Windows 2000, 
or the like), and some amount of disk storage and system memory. Using the IN 

15 boxes, the enterprise (or the CDNSP on its behalf) has the ability to map and load 
balance users inside the enterprise (perhaps as part of the global ICDN), to fetch 
content from inside the firewall, to collect log information, to deploy software, to 
distribute live streams, and to provide other ICDN functionality. 

Thus, an illustrative enterprise CDN ("ECDN") is comprised of a variety 

20 of origin and surrogate servers and a distributed set of intelligence nodes (IN). An 
origin server can be any server that is intended to respond to a user request for 
information and includes, for example, common caching appliances, application 
servers, distributed storage and database management systems, and streaming 
media servers. The intelligence nodes tie the entire set of distributed nodes and 

25 services into a single, virtual service cloud. The ECDN intelligence nodes may 
have different configurations. Thus, for example, a first type (e.g., IN 212a in 
central office 200) may be sized (in terms of processing power and memory) for 
the largest datacenters, and such machines would be aggregation points for 
monitoring, logging, management and request routing. A second type of 
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intelligence node (e.g., IN 212b) may be sized for branch office deployment, and 
such servers would be sized to optimize local behavior. The nodes may be placed 
in a hierarchy with an IN of the first type acting as a parent. An intelligence node 
of the second type would typically include a caching engine. 
5 Architecturally, an ECDN such as illustrated above is similar to an Internet 

content delivery network (ICDN) and comprises: HTTP, streaming and DNS 
server nodes deployed across a customer network. Generalizing, the ECDN 
provides the enterprise with the following: a namespace and an associated request 
routing mechanism (to control how to navigate the CDN), storage, caching and 
1 0 streaming (to control how and where are objects stored and distributed), optionally 
an application environment (to facilitate application extensibility), management 
and provisioning (to control how the CDN is deployed and managed), and 
reporting/auditing (to provide visibility into the behavior). An ECDN such as 
described above provides an application, streaming and content delivery platform 
1 5 so that enterprise content may be delivered and managed in a decentralized fashion 
while providing a tightly-integrated solution with a customer's storage, network, 
application and management solutions. 

Enterprises today either outsource their Domain Name Service (DNS) or, 
as described above, run a DNS infrastructure (e.g., one or more DNS servers). A 
20 DNS namespace has certain characteristics, as are well-known. Each unit of data 
in a DNS distributed database is indexed by a hostname. These names are simply 
leaves in a tree representation, which is often called a domain namespace. Each 
node in the tree is labeled with a simple name. The fully qualified hostname of 
any node in the tree is the sequence of lables on the path from that node to the 
25 root. A zone is a subtree of the domain name space. Names at the leaves of the 
tree generally represent individual hosts, whose names resolve to one or more IP 
addresses. It has become common in instances of virtual hosting within ISPs to 
have multiple customers share a single machine, therefore having multiple 
hostnames reolve to a single machine or server farm. CDN technology to date has 
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additionally made it common for a single hostname to potentially resolve to any 
one of thousands of machines, though at any given time the set of possible 
hostnames is configured and fixed. The term zone usually relates to a set of hosts 
within a single authoritative server's namespace, whereas a single zone could 
5 include multiple sub-domains. Thus, e.g., iffoo.com and eng.foo.com are both 
handled by the same nameserver, they are both in the same zone; but, if fooxom's 
nameserver refers a lookup to a different authority for resolution, they would be 
considered separate zones. 

An organization administrating a domain can divide it into subdomains. 

10 Each of those subdomains can be delegated to other organizations, in which case 
the organization receiving the delegation becomes responsible for maintaining all 
the data in that subdomain. The machines or programs executing on those 
machines that store information about the domain namespace are often called 
name servers. Name servers generally have complete information about some part 

15 of the doman namespace, namely, a zone. In such case, the name server is then 
said to have authority for that zone. A name server can also maintain cached 
information - or non-authoritative information, which is obtained by 
communicating with an authoritative name server. A zone contains the domain 
names and data that a domain contains, except for domain names and data that are 

20 delegated elsewhere. If a subdomain of the domain has not been delegated, the 
zone also contains the domain names and data in the subdomain. 

For purposes of the present invention, it is assumed that the enterprise 
operates (or has operated) DNS servers, that those servers manage data held in 
zones, and that each zone is a complete database for a particular "pruned" subtree 

25 of the domain space. As noted above, the zone data is authoritative, in that it 
contains an accurate (typically, the most accurate) representation available for a 
particular set of hostnames. At least one host in the enterprise stores enterprise 
content that the enterprise desires to make available to permitted end users 
(enterprise or partner employees). The enterprises use the existing DNS 
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infrastructure to resolve client requests for content at that host. Figure 3 illustrates 
the known prior art. In this example, it is assumed that the user desires to retrieve 
the enterprise internal homepage, which is a page located, in this example, at 
http://hr.company.com/homepage.html. To this end, the user, or client 300, 
5 interacts with DNS via a resolver 302, typically residing on the same machine. As 
is well-known, a resolver is a client process that accesses a name server. 
Programs running on a host that need information from a domain name space use 
the resolver. In DNS BIND, for example, the resolver is a set of library routines 
that query a name server, interpret responses, and return the information to the 
10 program/process that requested it. Thus, with reference to Figure 3. the resolver 
302 interacts with the enterprise name server 304 to resolve client queries, which 
are then returned to the client. In the example shown in Figure 3, the client 
resolver 302 makes a DNS request (in this example "who is hr.company.com?") to 
the corporate DNS name server 304, which returns a reply with an actual IP 
15 address y.y.y.y of the host on which the document is stored. The client resolver 
i 302 then uses a DNS A record to build a connection to the actual web server 306, 

i and issues an appropriate HTTP request to the web server 306 (e.g., via a GET 

j httD://hr.companv.com/homepage.htmn . The web server 306 responds with the 

i 

\ content reply to complete the request. 

| 20 According to the invention, the existing DNS infrastructure is augmented 

| with one or more ECDN zone servers, and requests for content to be delivered 

over the ECDN are resolved through the one or more zone servers. In the 
>! simpliest embodiment, this function is achieved by identifying a given enterprise 

domain to be published to the ECDN, and having a network administrator (or a 
25 person acting on the administrator's behalf) modify an existing DNS name record 
for that enterprise domain. In this embodiment, the administrator CNAMEs the 
enterprise domain to a domain identified by a so-called "virtual" zone that is 
managed on an ECDN zone server (and, thus, forms part of the ECDN). In 
particular, this process enables the enterprise domain to be managed (by the 
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enterprise or a third party acting on the enterprise's behalf) as part of the ECDN, 
typically by the ECDN zone server on one of the intelligent nodes (or some other 
machine, such as a client name server). A similar process is repeated for every 
new domain or subdomain being distributed by the ECDN. Any client 
5 downloading a URL referring to the enterprise domain then gets directed to the 
ECDN zone server, which directs the client to an ECDN IN. The client passes a 
host header to the ECDN IN to identify the actual host. 

Figure 4 illustrates an embodiment of the present invention. DNS requests 
typically occur over UDP, while HTTP requests typically occur over TCP. The 

10 enterprise is identified as "akamai" for illustrative purposes only. In this example, 
the client resolver 402 makes a DNS request for "hr.akamai.com" (step (1)) to the 
configured name server 404. This name server may be part of the legacy DNS 
infrastructure, as described above. This same name server 404 (running a suitable 
DNS BIND version) looks up hr.akamai.com and sees that the hostname resides 

15 within the zone configured to be within the ECDN (potentially after first resolving 
a CNAME from hr.akamai.com to itself for hr.ecdn.akamai.com). At step (3), the 
query is then referred to an ECDN name server 406, with the ECDN name server 
being configured to be authoritative for the ecdn.akamai.com zone. Some of the 
steps are compressed in the figure for clarity. At step (4), the ECDN zone server 

20 406 could do one of three things: reply with an IP address x.x.x.x, pass the query 
to a different zone for hr.ecdn.akamai.com, or CNAME the request to a different 
hostname all together (restarting this process). In the drawing, the ECDN zone 
server has returned the IP address. Thus, at step (5), the client makes an HTTP 
request to the ECDN IN 408 at IP address x.x.x.x with a host header: identifying 

25 the host hr.akamai.com. At steps (6), (7) and (8), the ECDN content server 

handles the HTTP portion of the request in the standard fashion for a surrogate. 
The content is served from the origin server 406. 

The technique shown in Figure 4 provides significant advantages. 
According to the invention, when a DNS query arrives for a hostname known to 
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; 



10 



be associated with given content within the control of (i.e., managed by) the 
ECDN, the DNS server that receives the query preferably responds in one of three 
(3) ways: (a) handing back an IP address, e.g., for an ECDN intelligent node that 
knows how to obtain the requested content from a surrogate or origin server (as 
illustrated in Figure 4); (b) executing a zone referral to a next (lower) level in a 
zone hierarchy (as defined in standard DNS), or (c) CNAMing to another 
hostname, thereby essentially restarting the lookup procedure. This new CNAME 
cause the resolution process to start back at the root and resolve a new path, 
probably along a different path in the hierarchy. At any particular level in the zone 
hierarchy, there is preferably an associated zone server. Zone servers may operate 
on the same machines but typically have different IP addresses. Each zone server 
preferably executes logic that applies the requested hostname against a map which, 
using known techniques, maybe generated from given (static, dynamic, internally- 
. generated or third party-sourced) performance metrics. Thus, a given name query 
1 5 to ECDN-managed content may be serviced in coordination with various sources 
of distributed network intelligence. As a result, the invention provides for a 
distributed, dynamic globally load balanced name service for an enterprise CDN. 

From a logical view, hierarchical DNS zones for resolving a particular 
query within a content delivery network are represented according to the present 
20 invention as illustrated in Figure 5. In this example, it is assumed that an Internet 
CDN service provider operates over a namespace that is referred to as "akamai." 
This namespace includes a subdomain of *.ecdn.akamai.com, which, as noted 
above, is the virtual zone. In this example, the CDNSP manages the zone on the 
enterprise's behalf. In a normal name query, a request for foo.akamai.com returns 
25 some IP address, which is normally fixed. With web hosting, as is well-known, 
virtual hostnames are often used to allow a single address to handle multiple 
hostnames. For load balancing, a round robin technique is often used, allowing 
for one name to be spread across multiple addresses. For virtual zones, preferably 
there is a many-to-many mapping. In particular, one hostname is spread across a 
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mesh of servers, and one server may handle any number of hostnames. Thus, for 
example, in a simple case, one could create three (3) hostnames (x, y, and z) and 
have four (4) servers (having IP addresses: 1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4). Any 
hostname query could resolve to any server address, giving twelve (12) 
5 combinations of responses to any particular query. Thus, when the server for this 
virtual zone gets a request, it replies with any of the 12 possible addresses, 
although significant performance advantages could be gained if it were to use a 
more intelligent approach. In particular, it is also well-known that geographical 
and topological location information can be used to send clients to the closest 

10 address, and server load can be accounted for as well to try and optimize client 
response times. A combination of these (with other factors) can be used to 
determine the best server for handling a particular request. 

As described above, so-called Canonical Name (CNAME) records define 
an alias for an official hostname and are part of the DNS standard. In general, 

1 5 CNAMEing may be thought of as a means for DNS redirection of a client query. 
As illustrated above, DNS virtual zones and CN AMEs are used with standard 
surrogate servers to manage ECDN content in a given enterprise. 

The CNAME technique may be implemented any number of arbitrary 
times, while zone referral preferably occurs hierarchically. Generalizing, 

20 according to the invention, a given domain maybe of the form 

"*.zone2.zonel. enterprise.com" where "zonel" represents a first or "top" level 
ECDN zone, "zone2 "represents a second or "lower" level ECDN subzone of the 
top level zone, and so forth. As indicated in Figure 6, a first level ECDN zone 
server 600 would handle top level resolutions, and one or more second level 

25 ECDN zone servers 602 would handle the next level resolutions, and so forth. 
The wildcard "*" in the above example indicates that further zone levels may be 
provided as well, with each level of the zone hierarchy then inheriting the 
namespace of the levels above it. Thus, the "virtual" nature of the invention is due 
to the fact that at no time is there necessarily a fixed set of possible hostnames - 
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they may be, and most likely are, produced on-the-fly. Thus, for example, if the 
enterprise uses an Oracle database for storing financial data, the network 
administrator may generate domains such as M fmancials.ecdn.company.com," 
while the ECDN itself may be creating objects like 
5 "component.oracle.financials.ecdn.company.com," or 

"a.b.c.oracle.financials.ecdn.company.com" etc. Continuing with this example, if 
a particular ECDN zone server is provided with a name it does not fully recognize, 
it resolves that portion that is can recognize. Thus, while a first-level ECDN DNS 
server might do a rough cut of performance and refer a request to another zone, the 
10 next zone may have a finer grain metric used for next step resolution. 

According to the invention, and as illustrated in Figure 6, assume that 
given enterprise content has been published to the ECDN and, in particular, to be 
managed by a second level zone server "hr.ecdn.akamai.com." In this example, a 
request for resolution ofhr.akamai.com is first directed (through a CNAME) to the 
1 5 ecdn.akamai.com top level zone server 600, which then redirects the request 
(again through a CNAME) to one of the hr.ecdn.akamai.com second level zone 
servers 602. The second level name servers may be load balanced, e.g., based on 
network information collected at the zone server pair about connectivity between 
the remote office and possible locations of the backend servers that host the 
20 desired content, as well state information about the load on those servers. The 
second level name server returns the IP address of an optimal backend server 
based on the available metrics (e.g., server load, network connectivity, etc.). The 
use of hierarchical zones in this manner enables the enterprise to build and 
maintain more relevant "local" information about how client requests should be 
25 mapped, thus obviating the building, maintenance and delivery of enterprise-wide 

request routing maps. 

According to another feature of this invention, a software agent is executed 
in or in conjunction with a DNS server to create "zones" dynamically. In this 
approach, the agent, in effect, provides hints to the enterprise DNS name server as 
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to which enterprise domains would be beneficially cached, as well as the addresses 
of near-by (local) ECDN intelligent nodes. Figure 7 illustrates the agent-hinted 
CNAME technique. To create such as agent, the enterprise may keep a 
lightweight history databases within a DNS server, recording usage patterns of A 
5 (address) record lookup requests. Building heuristics around access patterns or 
looking for high or relatively increased lookups on a per domain basis might 
provide candidate hostnames. This would identify high usage HTTP sites. The 
hints might also come from firewalls, third party updates, in-line L4 switches, or 
from some other entity listening on port 80 (e.g., perhaps via an egress switch 

10 SPAN port). When a domain is identified as potentially interesting from a usage 
perspective, instead of returning the address of the actual domain, the address of a 
nearby ECDN IN may be substituted dynamically. After traffic dies down, the 
address could revert back to standard behavior. Thus, if the "hot" domain is 
"hr.akamai.com," the DNS name server dynamically CNAMEs the domain to the 

15 local ECDN zone server "ecdn.akamai.com" as needed. All traffic to the 

hr.akamai.com would then get sent to the close-by ECDN IN for handling. Agent 
interaction may be accomplished as a server plugin, through WCCP 2.0 
transparent interception of DNS traffic, promiscuous DNS port snooping (SPAN 
mode), or providing an augmented DNS name server. An interface may be 

20 provided to notify the agent that all *. ecdn.enterprise.com servers are part of the 
ECDN and should be sent towards the appropriate servers. 

The present invention provides numerous advantages over the prior art. 
According to the invention, a domain to be published to the ECDN is associated 
(either by static configuration or dynamically) with a set of one or more enterprise 

25 zones configurable in a hierarchy. When a request for content is received from a 
given client in the enterprise (or otherwise accessible through the firewall), a name 
query to the enterprise's legacy DNS is directed (preferably via CNAME) to a set 
of one or more ECDN zone servers. A given ECDN zone server associates a 
name query with an ECDN intelligent node (or to a given content server). This 
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association may be based on given conditions within the network, server load 
conditions, or some combination of various known metrics. With ECDN virtual 
zones, maps that associate a given request to a server may be local or global, static 
or dynamic. If multiple zones are used in a hierarchy, a first level ECDN zone 
5 server redirects the name query to a second level ECDN zone server, and so on, 
until the appropriate response is generated. ECDN zone servers may reside on the 
same machine or with existing DNS infrastructure or other machines in the 
enterprise. This enables the present invention to be readily integrated into an 
existing or legacy DNS solution with minimal reconfiguration. 
10 As described and illustrated above, a given zone may have a sub-zone and, 

according to the invention, that sub-zone may be managed by the enterprise or 
even by a third party such as an Internet content delivery network (ICDN) service 
provider. As an example of the latter scenario, assume that the enterprise 
outsources its streaming video delivery to the ICDN service provider. To this end, 
15 a host lookup for, say, allhands.streamingvideo.ecdn.company.com may be 

configured either statically or dynamically to a zone managed by a CDN overlay 
network. This has the effect of transparently allowing delivery to be seemlessly 
tied internally and externally via the same mechanism. 

Figure 8 illustrates another example of how an enterprise may hand off 
20 management of a virtual zone to another entity, in this case an enterprise business 
partner. In this example, producer.com is the enterprise and consumer.com is the 
enterprise business partner having an end user. Producer.com desires to make 
given content available to the consumer.com end user, however, the producer.com 
namespace on which the content is published is not resolvable through public 
25 DNS and the document is not available publicly. Both producer.com and 

consumer.com are assumed to have implemented an ECDN system behind each of 
their respective firewalls, and each entity has a private namespace that they 
respectively manage. The goal is to make producer.com's namespace selectively 
available to an end user in consumer.com without, at the same time, exposing 
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producer.com's namespace to the public DNS. Each ECDN deploys a relay 
machine which, preferably, is a combination of a surrogate origin server and an 
ECDN zone server Separate machines/processes may be used, or the processes 
may be integrated or included with other functionality. Preferably, each relay 
5 machine is located within the enterprise DMZ, as illustrated in the drawing. The 
relay machine inside consumer.com does not know how to resolve a virtual zone 
associated with producer.com, but that machine does know that the relay machine 
inside producer.com's firewall does know how to make such a resolution. 
Likewise, the relay machine inside producer.com does not know how to resolve a 
10 virtual zone associated with consumer.com, but that machine does know that relay 
machine insideconsumer.com' s firewall make know how to make such a 
resolution. As is well-known, boxes within a DMZ can be selectively allowed to 
communicate with one another while filtering other potentially hostile 
communications. 

1 5 Referring back to Figure 8, assume that the document in question is 

referenced within consumer.com by a836.asp.producer.com/object.html. In this 
example, the zone "asp.producer.com" has been designated within consumer.com 
as being owned or managed by relay.consumercom. Thus, relay.consumer.com 
will act as a surrogate for that document. When the consumer.com relay gets the 

20 host header a836.asp.producer.com, the relay machine uses that information to 
connect to the relay machine in producer.com. The relay machine in 
producer.com gets the HTTP request and it is configured to rewrite any host 
header (associated with a836.asp.producer.com in this example) to 
foo.producer.com. The relay machine at relay.producer.com then acts as a 

25 surrogate origin server for the web server at foo.producer.com, which hosts the 
document. The web server then returns the document via the surrogate origin 
server relay.producer.com, and that server rewrites the response header to point 
back to itself. The relay machine in producer.com then returns the data to the 
relay machine in consumer.com, which performs similar surrogate processing and 
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returns the document to the requesting end user. This completes the processing. 
Thus, one of ordinary skill in the art will appreciate that, in this manner, 
producer.com has handed off management of the relay.producer.com virtual zone 
to consumer.com. This arrangement creates a VPN-like connection between the 
5 two namespaces to facilitate the document sharing. As illustrated, preferably the 
communications between the two relay machines are made over secure link using 

known techniques. 

Having thus described my invention, the following sets forth what I now 

claim. 
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CLAIMS 



1. 



A content delivery method operative in an enterprise, comprising: 



10 



15 



20 



establishing an enterprise content delivery network within the enterprise, 
wherein the enterprise content delivery network has associated therewith a set of 
one or more zones organized into a hierarchy; and 

in response to a name query for a hostname known to be associated with 
the given content being managed by the enterprise content delivery network, 
returning a response to the name query, 

wherein the response selectively (a) identifies a given node in the 
enterprise content delivery network that can obtain the given content from a server 
within the enterprise, (b) causes a referral to a zone within the hierarchy, or (c) 
relays the name query to another path. 

2. The content delivery method as described in Claim 1 wherein, if 
the response identifies the given node, having the given node obtain the given 
content from the server. 

3. The content delivery method as described in Claim 1 wherein, if 
the response causes a zone referral, attempting to resolve the name query at a next 
level within the hierarchy. 

4. The content delivery method as described in Claim 1 wherein, if 
the response is relayed to another path, attempting to resolve the name query along 
that path. 

5. The content delivery method as described in Claim 1 further 
including the step 

publishing the given content into the enterprise content delivery network. 
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6. The content delivery method as described in Claim 5 wherein the 
step of publishing comprises: 

identifying the hostname to be published to the enteiprise content delivery 

network; 

5 aliasing the hostname to a given zone in the hierarchy. 

7. The content delivery method as described in Claim 6 wherein the 
aliasing step CNAMEs the hostname to a domain in which the virtual zone is 
prepended to at least a portion of the hostname. 

10 

8. The content delivery method as described in Claim 7 wherein the 
CNAME is generated statically. 

9. The content delivery method as described in Claim 7 wherein the 
1 5 CNAME is generated dynamically. 

1 0. The content delivery method as described in Claim 1 wherein the 
name query is resolved to the IP address of the given node a* a function of given 
network or server metrics. 

20 

1 1 . The content delivery method as described in Claim 10 wherein the 
IP address of the given node is generated dynamically. 

12. The content delivery method as described in Claim 1 wherein the 
25 enterprise content delivery network is part of an Internet content delivery network 

(ICDN). 

13. The content delivery method as described in Claim 1 1 wherein the 
enterprise content delivery network is managed as part of the ICDN. 



BNSOOCID: <WO_O20696C6A3_IA> 




BNSDOCID: <WO_02069608A3_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 02/069608 



PCT/US02/01079 



2/4 



REMOTE OFFICE 



CENTRAL OFFICE 



ECON NOOES 




FIG. 2 



"Ml2b 



WEB SERVER NODES 



CORPORATE DNS 
NAMESERVER 



-304 



y-y-yy 

2 



yyyy 

(hr.akamai.com) 



306-J! 



GET http://hr.okomai.com/homepoge.html 



hr.akamai.com? 
1 



CLIENT 
RESOLVER 



■DNS VIA UDP 
-HTTP VIA TCP 



CONTENT REPLY 
4 




FIG. 3 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCIO <WO_02Ce8808A3_IA> 



WO 02/069608 



PCT/US02/OJ079 



'3/4 



y-yy-y 

(origin-hr.akamai.com) 



410x 



CONTENT 
REPLY 



ECDN ZONE CLIENT 
SERVER NAMESERVER 

X406 



GET http://origin-hr. 

akamai.com/ 

homepage.html 

6 

5 



CNAME TO t 
hr.ecdn.akamai.com hr.akamai.com? 

2 r 



hr.ecdn? 



x.x.x.x 



CLIENT 
RESOLVER 



-402 



□ o onoeooD o 
^gg^ Qo o □ ooooD o 



GET http://hr.akomai.com/homepage.html 



x.x.x.x 



DNS VIA UDP 
■ HTTP VIA TCP 



CONTENT REPLY 
8 



FIG. 4 



o 




zonel .enterprise.com 



FIRST LEVEL 
ZONE SERVER 




602xr 
zone2.zone1 .enterprise.com 



m 



-600 



METRICS 



SECONO LEVEL 
ZONE SERVER(S) 



r 602 

TL 

-J x 602 



TO FURTHER LEVELS 
IN ZONE HIERARCHY 

FIG. 6 



FIG. 5 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO__020e960eA3JA> 



WO 02/069608 



PCT/US02/01079 



4/4 



FIG. 7 



X.X.X.X IS AN ECDN SERVER 
DYNAMICALLY CNAME producer.com 
TO LOCAL ECDN SERVERS 



ECDN 
DNS AGENT 



AGENT/ECDN 
COMMUNICATION 



DNS VIA UDP 



ECDN NODE 

x*x.x.x 



LOCAL ONS 
NAMESERVER 



www.producer.com? 



(Q 




CLIENT 



t 



producer.com 
DMZ 



consumer.com 
DMZ 




WEB SERVER 
foo.producer.com 



ECDN CLIENT 



fig. a 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCIO: <WO_0206960SA3_IA> 



INTERNATIONA 



IEARCH REPORT 



fpf tal Application No 
PCT/US 02/01079 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L29/12 H04L29/06 



According to International Patent Classification (IPC) or to both nation al classification and IPC 
B. FIELDS SEARCHED 



MinTrnum documentation searched (dassmcalion system followed by dassifteatton symbols) 

IPC 7 H04L 



Documematlon searched other than minimum documentation lo the extent that such documents are included in the fields searched 



Electronic data base consulted during the International search (name of data 

EPO-Internal 



base and. where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 0 



Citation of document, wflh indication, where appropriate, of the relevant passages 



Relevant to claim No. 



WO 99 40514 A (SALTER JAMES A ;FARBER 
DAVID A (US); GREER RICHARD E (US); SWART 
A) 12 August 1999 (1999-08-12) 
abstract 

page 2, Une 18 -page 3, line 17 
page 4, Une 1 -page 5, Une 24 
page 6, line 24 -page 8, Une 12 
page 12, line 9 -page 12, Une 15 
page 13, Une 3 -page 13, Une 13 

US 6 108 703 A (LEWIN DANIEL M ET AL) 
22 August 2000 (2000-08-22) 
abstract 

column 3, line 24 -column 4, Une 22 

-/- 



1-4, 
10-13 



1-4, 
10-13 



LH 



Further documents are listed in the continual Ion of box C. 



Patent family members are listed In annex. 



" Special categories of died documents : 

•A* document defining Ihe general state of the art which is not 

considered to be of particular relevance 
•E # carter document but published on or after the international 

filing dale 

•f document which may throw doubts on priority ctejm(s)or 
which is cited to est a Wish me publication date of another 
citation or other special reason (as specified) 
■0" document referring to an orat disclosure, use, exhIMIonor 
other means 

•p* document published prior to the international Wing dale but 
later than the priority date claimed 



T later document published after the international ruing date 
or priority date and not in conflict with the application but 
died to understand the principle or theory underlying the 
invention 



•X' 



document of particular relevance; the dawned invention 
cannot be considered novel or cannot be considered to 
Involve an mvenirve step when the document is taken alone 
•Y* document of particular relevance; the claimed invention 

cannot be considered lo involve an Inventive step when the 
document is combined wflh one or more other such docu- 
ments, such combination being obvious to a person sWlad 
In the art. 

•4* document member of the same patent family 



Date of the actual completion of Ihe international search 



5 September 2002 



Date of mailing of the international search report 

13/09/2002 



Name and mailing address of the ISA 

European Patent Office, P.B. 5618 Palenlkaan 2 
NL-2280HVR^swijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl, 
Fax (+3 1-70) 340-3016 



Authorized officer 



Goller, W 



Form PCTrtSA/210 (5#eond$h#«t) (July 1992) 



page 1 of 2 



BNSDOCID: <WO_020686O8A3 IA> 



INTERNATIONAI 



RCH REPORT 



C^ConUmiaUon) DOCUMENTS CONSIDERED TO BE RELEVANT 



I^^J \a\ Application No 

PCT/US 02/01079 



Category • I Citation of document, with indication. where appropriate. ©I the relevant passages 



EP 0 817 444 A (SUN MICROSYSTEMS INC) 
7 January 1998 (1998-01-07) 
abstract 

line 20 -column 3, line 41 
Hne 50 -column 6, line 57 
line 30 -column 7, Hne 40 



column 2, 
column 5, 
column 7, 



WO 00 74347 A (ENTERA INC) 
7 December 2000 (2000-12-07) 
abstract 

page 5, Hne 4 -page 6, Hne 18 
page 9, Hne 2 -page 9, Hne 24 



Relevant to claim No. 



1,2, 
10-13 



1-4, 
10-13 



form PCT/1SA/210 (ccrtlntMiion erf t*oond ttwel) (July 1992) 
BNSDOCID: <WO_02069608A3JA> 



page 2 of 2 



INTERNATIOI^^EARCH REPORT 

formation on patent family 



Patent document 
cited in search report 



Publication 
date 



al Application No 

PCT/US 02/01079 



Patent family 
member(s) 



WO 9940514 



12-08-1999 



Publication 
date 







81 


06-02-2001 


All 
nU 




A 


23-08-1999 


CA 


2320261 


Al 


12-08-1999 


EP 


1143337 


Al 


10-10-2001 


EP 


1053524 


Al 


22-11-2000 


JP 


2002503001 


T 


29-01-2002 


NO 


20004010 


A 


10-10-2000 


US 


2002049857 


Al 


25-04-2002 


US 


2002099850 


Al 


25-07-2002 


WO 


9940514 


Al 


12-08-1999 


us 


2001056500 


Al 


27-12-2001 



US 6108703 


A 


22- 


-08- 


•2000 


AU 


4995299 A 


07-02-2000 










BR 


9912001 A 


04-12-2001 












CN 


1312923 T 


12-09-2001 












DE 


1125219 Tl 


23-05-2002 












EP 


1125219 Al 


22-08-2001 












JP 


2002520735 T 


09-07-2002 












WO 


0004458 Al 


27-01-2000 












US 


2002099850 Al 


25-07-2002 


EP 0817444 


A 


07- 


-01- 


-1998 


US 


6154777 A 


28-11-2000 










EP 


0817444 A2 


07-01-1998 












JP 


10126445 A 


15-05-1998 


WO 0074347 


A 


07- 


-12- 


-2000 


AU 


4661600 A 


18-12-2000 










WO 


0074347 Al 


07-12-2000 



Form PCTASA/210 (patent lamiy anna*) (Ju»y ^932) 



BNSDOCID: < WO_02OQ960BA3_ IA> 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 
Q^FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 
J3^RAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



THIS RAGE BLANK (uspto) 




